Thanks for the PR — the implementation is clean and well thought through: pure CoreAudio with no new deps, remembering the exact device so a mid-session default-route change can't strand the wrong one, skipping devices the user had already muted, and gracefully handling devices without a master-mute property. Nice work.

I'd like one design change before merging, plus one robustness fix.

1. Make it an opt-in setting (default off), not automatic

I'd prefer muting to be a user choice rather than always-on. kAudioDevicePropertyMute toggles the mute of the entire output device system-wide (the same mute as the keyboard mute key / the menu-bar volume), so for a menu-bar dictation tool that records on every hotkey press, silencing all system audio every time is surprising for anyone who dictates while listening to music, a meeting, or a video. This is also how comparable tools (e.g. Typeless) handle it — you can choose to mute playback or leave it alone.

Concretely, this can follow the existing feedback.start_sound path end to end:

• add a bool field in koe-core/src/config.rs (mirror FeedbackSection);
• read it at runtime like sp_core_get_feedback_config() (or via the generic configGet);
• add an NSSwitch in the General pane of SPSetupWizardWindowController (next to the Trigger / Feedback Sounds cards), wired into saveConfig: and the load path via configSet/configGet;
• gate the [self muteSystemOutput] call in SPAudioCaptureManager behind the flag — e.g. a muteOutputEnabled property that SPAppDelegate sets before startCapture, the same way pendingDeviceID is injected.

The default should be off, so existing users' behavior is unchanged and the people who want it can turn it on.

2. Restore on abnormal exit

restoreSystemOutput only runs from stopCapture. If the app crashes, is force-quit, or is killed while recording, the device stays muted — and because device mute is a persistent system property, the user is left with silent output and no obvious cause, even after relaunching the app. Please also restore on applicationWillTerminate: to cover a normal quit while recording. SIGKILL can't be caught, which is also a reason to reconsider whether a global device-level mute is the right hammer here versus a lighter approach — happy to discuss.

Minor

• Once it's a setting, please reword the CHANGELOG entry (it currently says "automatic muting…"), e.g. "optional setting to mute system audio while recording (off by default)".

Everything else looks solid: the mute/restore pairing is balanced and idempotent across the various stopCapture call sites, and remembering the muted device (instead of re-reading the default output at stop) correctly handles a mid-recording output change. Thanks again — looking forward to the updated version!